Methods and apparatus for dynamic user authentication using customizable context-dependent interaction across multiple verification objects

ABSTRACT

An authentication framework is provided which enables dynamic user authentication that combines multiple authentication objects using a shared context and that permits customizable interaction design to suit varying user preferences and transaction/application requirements. Such a framework provides a high degree of flexibility, accuracy, convenience and robustness. In one illustrative aspect of the invention, an automated technique for user authentication comprises the following steps/operations. First, user input is obtained. At least a portion of the user input is associated with two or more verification objects. Then, the user is verified based on the two or more verification objects in accordance with at least one verification policy operating on a context shared across the two or more verification objects. The user authentication technique of the invention may preferably be implemented in a flexible, distributed architecture comprising at least one client device coupled to at least one verification server. The client device and the verification server may operate together to perform the user authentication techniques of the invention.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of U.S. application Ser. No.10/283,729 filed on Oct. 30, 2002, the disclosure of which isincorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to authentication techniques and, moreparticularly, to techniques for providing dynamic user authenticationusing customizable context-dependent interaction across multipleverification objects.

BACKGROUND OF THE INVENTION

Authenticating the identity claim of a user is an important step inensuring the security of systems, networks, services and facilities,both for physical and for logical access. Existing user authenticationis often performed on the basis of a user's knowledge of a singleverification object, e.g., a password or a personal identificationnumber (PIN). Existing user authentication may also be performed on thebasis of possession of a single verification object, e.g., a key or acard. Other existing authentication techniques include the use of asingle biometric feature as the verification object, e.g., afingerprint, a voiceprint, an iris scan or a face scan.

Verification is typically done by comparing the verification objectobtained from the user at the time of attempted access to previouslystored objects. Thus, in the case of a fingerprint, if the fingerprintobtained from the user at the time of attempted access matches aprestored fingerprint (presumably taken from the user at some earliertime), then access is granted. If no match is found, then access isdenied.

However, these existing authentication techniques have many drawbacks.For example, keys or passwords may be stolen or biometric features maybe compromised, e.g., using false fingerprints.

More recent techniques attempt to use more than one biometricrecognition technique, such as face and voice print recognition.However, such techniques typically acquire and analyze each biometricfeature sequentially and independently and merely combine the finaloutputs in a predetermined static manner, and thus do not utilize anyinteraction between biometrics.

Further, existing authentication techniques fail to provide enoughflexibility to address various user-specific, transaction-specific orapplication-specific constraints or requirements. For example, auser-specific constraint may be that a user with a cut on his finger maynot be able to use a fingerprint recognition system. Atransaction-specific constraint may be that a million dollar transactionshould require a higher degree of authentication as opposed to a tendollar transaction. An application-specific constraint may be thatsecurity questions based on a banking application may not be suitablefor a travel application. Existing authentication approaches are justnot flexible enough to handle these types of constraints orrequirements.

Accordingly, given the growing interest in security and authenticationand the deficiencies of existing authentication systems, there is aclear need for an improved authentication framework that provides a highdegree of flexibility, accuracy, convenience and/or robustness.

SUMMARY OF THE INVENTION

The present invention provides an improved authentication frameworkaffording greater flexibility, accuracy, convenience and robustness ascompared to existing authentication frameworks. This is accomplished,for example, by enabling dynamic user authentication that combinesmultiple authentication objects using a shared context and that permitscustomizable interaction design to suit varying user preferences andtransaction/application requirements. Such a framework advantageouslyprovides a high degree of flexibility, accuracy, convenience androbustness.

In one aspect of the invention, an automated technique for userauthentication comprises the following steps/operations. First, userinput is obtained. At least a portion of the user input is associatedwith two or more verification objects. Then, the user is verified basedon the two or more verification objects in accordance with at least oneverification policy operating on a context shared across the two or moreverification objects.

The user verification step/operation is preferably performed inaccordance with two or more verification engines which are respectivelyresponsive to the two or more verification objects. The two or moreverification engines may respectively compare the two or moreverification objects to at least one user model. The user model may bepreviously generated based on data obtained in accordance with a userenrollment session.

Further, the context that is shared across the two or more verificationobjects may comprise one or more variables associated with the userverification step/operation. For example, the context variables mayrepresent one or more of: (i) a user name; (ii) a current state in theat least one verification policy; (iii) a history pertaining to the twoor more verification objects; (iv) application-specific requirements;(v) user-specific requirements; and (vi) physical or logical variables.Still further, the two or more verification objects may represent objecttypes that may be used to verify identity of the user, knowledge of theuser, and possessions of the user.

In another aspect of the invention, the user authentication technique iscustomizable in that the technique may comprise the steps/operations ofadding, modifying and/or deleting a verification policy, a verificationobject type, a user model, and/or a variable associated with thecontext. These tasks may be accomplished in an administrative session.

In yet another aspect of the invention, the user authenticationtechnique is implemented in a flexible, distributed architecturecomprising at least one client device coupled to at least oneverification server. The client device and the verification server mayoperate together to perform the inventive user authentication techniquesdescribed herein.

A communication interface between the client device and the verificationserver may be implemented in accordance with Extensible Markup Language(XML). Such a communication interface between the client device and theverification server may support a verification session, an enrollmentsession and/or an administrative session.

In a further aspect of the invention, the user authentication techniquecomprises the use of at least one verification policy and verificationmeans operative to verify a user in accordance with the at least oneverification policy, wherein the at least one verification policy isimplementable in accordance with the verification means as a statemachine. It is to be understood that verification means, as referred toherein, may be realized in a number of implementations, e.g., averification module which can be implemented in hardware, software,and/or combinations thereof.

In yet another aspect of the invention, the user authenticationtechnique comprises the use of at least one verification object andverification means operative to verify a user in accordance with the atleast one verification object, wherein the at least one verificationobject is one of: (i) usable for verification without the use of anassociated verification engine; (ii) not required to be previouslyenrolled with user data relating to the at least one verificationobject; (iii) dynamic; (iv) implicit; (v) able to inherit at least oneproperty from another object; (vi) characterized by multiple inputs;(vii) weighted; and (viii) able to be manipulated. By implicit, it ispreferably meant that the object requires no user input, e.g., acaller-id based object. By inheritance, it is preferably meant that oneobject can inherit a property from another object, e.g., if an object iscalled color, a new object can be created called car color that inheritsproperties from the parent object (color).

In yet another aspect of the invention, the user authenticationtechnique comprises the use of at least one user model and verificationmeans operative to verify a user in accordance with the at least oneuser model, wherein the at least one user model is one of: (i)representative of one or more user preferences; and (ii) able to bemodified for use in subsequent user verification.

These and other objects, features and advantages of the presentinvention will become apparent from the following detailed descriptionof illustrative embodiments thereof, which is to be read in connectionwith the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a client-server architecture ofan authentication system for implementing customizable verificationusing multiple verification objects, according to one embodiment of theinvention;

FIG. 2 is a block diagram illustrating an exemplary computing systemenvironment for implementing customizable verification using multipleverification objects, according to one embodiment of the invention;

FIG. 3 is a diagram illustrating an exemplary specification of multipleverification objects, according to one embodiment of the invention;

FIG. 4 is a diagram illustrating an exemplary specification of usermodels including multiple verification objects, according to oneembodiment of the invention;

FIG. 5 is a diagram illustrating an exemplary specification ofcustomizable verification policies utilizing multiple verificationobjects for dynamic user authentication, according to one embodiment ofthe invention;

FIG. 6 is a state transition diagram illustrating state transition forthe example verification policy of FIG. 5; and

FIG. 7 is a flow diagram illustrating a verification session between averification client device and a verification server for the exampleverification policy of FIG. 5.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following description will illustrate the invention using anexemplary client-server system architecture. It should be understood,however, that the invention is not limited to use with any particularsystem architecture. The invention is instead more generally applicableto any system architecture in which it is desirable to provide anauthentication framework that provides a high degree of flexibility,accuracy, convenience and/or robustness. That is, the techniques of thepresent invention may be implemented on a single computer system or onmultiple computer systems coupled by a suitable network, examples ofwhich will be described below.

As will be illustratively explained in detail herein, the presentinvention provides a new programming model that allows fillcustomization of the authentication process to address a wide variety ofuser-specific, transaction-specific, application-specific constraintsand other related requirements, including multiple verification objects.

The invention further enables a dynamic user authentication process thatcan respond in real-time to changes in the interaction between the userand the system. The highly flexible architecture permits newverification objects and verification policies to be added at anytime. Acommon context and associated data structures are included, such thatthe entire authentication interaction can operate on this sharedcontext.

In one embodiment, the interaction design is based on authenticationpolicies implemented as a statistical state machine using XML(eXtensible Markup Language). In addition, there is a file thatspecifies the relevant authentication objects (e.g., questions to beasked, actions to be performed, etc.) and files that contain userprofiles (e.g., user selected authentication objects and correctresponses, user preferences, etc.) both of which may also be implementedusing XML.

The entire authentication interaction is determined dynamically based onthe authentication policy in effect (selected based on user preferencesand transaction or application requirements), using operations on theshared context, further utilizing the authentication objects in effectand the user profile of interest.

Such an approach provides significantly improved authenticationcapabilities as compared with existing authentication systems, andensures a very high degree of accuracy, flexibility, convenience androbustness.

Furthermore, as will be illustratively explained in detail below, theauthentication techniques of the present invention utilize the followingcomponents: (1) verification objects and verification engines; (2)verification policies and a verification policy manager; and (3) usermodels.

Verification objects are objects that can be used for the purpose ofverifying the identity of users, such as the user's biometriccharacteristics (e.g., voiceprint, fingerprint, face scan, iris scan,handwritten signature, keyboard dynamics, etc.), the user's knowledge(e.g., passwords, passphrases, answers to personal questions, etc.), andthe user's possessions (e.g., keys, cards, tokens, certificates,cellular telephone or home telephone transmitting caller-id information,personal or handheld computer with client software, user's location,etc.). It is to be understood that the lists of example objects aboveare not intended to be exhaustive and, further, that the invention isnot intended to be limited to any particular objects.

Verification engines are used to match the verification objects with therepresentation stored in a user model. Examples of verification enginesinclude a fingerprint recognition system to match the user'sfingerprint, a conversational system to evaluate spoken answers toquestions such as a voice response system, a conversational system suchas a speech or voiceprint recognition system (that may include naturalunderstanding techniques) to extract and recognize a user's spokenutterances (wherein the conversational system may also include a speechsynthesis system for generating synthesized questions and prompts), acaller-id recognition system to extract and match the user's telephonenumber, a badge reader to scan the user's badge or card, a PINconfirmation system to confirm a user's PIN, a face recognition systemto extract and match a user's face scan, an iris recognition system toextract and match a user's iris scan, a handwriting recognition systemto recognize a user's handwriting, a keyboard dynamic recognizer tomatch a user's keyboard dynamics, as well as other modality-specificengines discussed herein and/or may otherwise be known. It is to beunderstood that since these types of engine are well-known, furtherdescriptions of details of such engines are not necessary and thereforeare not provided herein. Again, it is to be understood that the list ofexample engines above is not intended to be exhaustive and, further,that the invention is not intended to be limited to any particularverification engines.

While verification engines typically perform user verification bycomparing user input to the user's model that was created when the userenrolled, the invention is not restricted to verification engines thatrequire user enrollment. Unsupervised verification engines, that do notrequire the user to enroll, may also be used. When unsupervisedverification engines are used, a single user model may be employed,including the user attributes as measured by the verification engines.For example, the following verification engines can be used: acousticaccent recognition, language identification, and face features detection(e.g., color of eyes, glasses detection). In this case, none of theindividual verification engines require user enrollment, and one usermodel is used, stating the user's speech accent spoken, language, colorof eyes, and whether he/she wears glasses.

Thus, the invention realizes that, while individual verification enginescan be used to perform simple verification steps that operate in apredefined static manner, a more general framework is necessary whenmultiple verification objects are used to perform dynamic userauthentication, in order to achieve a greater degree of accuracy andflexibility. The present invention provides such an improvedauthentication framework.

To accomplish this and other goals, the present invention introduces anotion of verification policies that govern the interaction between theuser and the overall system, including the authentication system, andbetween the various verification engines. Any number of verificationpolicies could be written to satisfy a wide variety of user-specific,transaction-specific or application-specific authentication needs,including needs that change in real-time.

As will be seen, such verification policies are managed by averification policy manager which uses operations on a common contextshared across all verification objects to achieve maximumprogrammability of the authentication system.

In one embodiment of the invention, the verification policies implementa finite state machine, operating on one or more verification objects.Starting from an initial state, transitions occur to other states as thevarious verification objects are manipulated, including terminal stateswhere the user is accepted or rejected. In some cases, there may bemultiple states that grant user acceptance, each with its own securitylevels (e.g., low security, medium security, high security, etc.) toaddress the changing security needs of the transaction being processed.The verification policy manager allows for new verification objects tobe added at any time, by including the specifications of the new objectsin a registry of verification objects, after which verification policiesinvoking the new verification objects may be utilized.

User models are typically created when a user enrolls in the system,using the inputs provided by the user (e.g., samples of voice, samplesof fingerprint, answers to personal questions, etc.), or acquiredthrough other means (details of past transactions, balance in mostrecent bill, serial number of a key or badge issued, encryption keycontained in a smartcard or a client software, etc.).

The user models may be updated in real-time when needed, such as when anew bill is issued and the balance changes or when more voice samplesare available. An individual user model contains information regardingall verification objects relevant to that user, including any userpreferences related to the verification objects (e.g., a user may preferquestions regarding colors rather than numbers). User models alsopreferably support nontrivial manipulations of the verification objects,such as asking the user to add the first and third digits of his socialsecurity number. Again, any of the above-mentioned examples are notintended to limit the invention.

Given the above general description of some of the principles andfeatures of the present invention, illustrative embodiments of theseprinciples and features will now be given in the context of the figures.

Referring initially to FIG. 1, a block diagram illustrates aclient-server architecture of an authentication system for implementingcustomizable verification using multiple verification objects, accordingto one embodiment of the invention. As shown, the authentication system100 comprises a verification client device 102 and a verification server104, coupled via a network adapter 106. The verification client 102 hascontext 108 and application 110 associated therewith. The verificationserver 104 comprises a verification policy manager 112 and a pluralityof verification engines 114-1 through 114-N, where N can be any integer2, 3, 4 . . . , and represents the number of verification objectfamilies or types that the particular implementation of the inventioncan support. The authentication system 100 further comprises a datamanager 116, a verification objects store 118, a verification policiesstore 120 and a user models store 122. While the data manager 116 anddata stores 118, 120 and 122 are shown outside of the verificationserver box, it is to be understood that they may be implemented on theverification server.

The verification client device 102 is responsible for interfacing withthe user and collecting the inputs from the user, communicating with theverification server 104 through the network adapter 106, andcommunicating with the application 110. In one embodiment of theinvention, the verification client device 102 is also responsible foracquiring and maintaining the context 108.

In an alternative embodiment, the context 108 may be stored on a centraldatabase (not shown), accessible by other components of the system 100.Such an implementation allows for a stateless operation between theverification client device 102 and the verification server 104, suchthat different servers could be used for different turns in theverification process, thereby providing protection against a particularserver going down in the middle of a verification process, and alsoallowing for improved load balancing of the server resources.

The context 108 records all relevant variables for the verificationprocess, such as: (1) the user name; (2) the current state in theverification policy that is in effect; (3) the history pertaining to theverification objects that have been invoked and the scores and outcomesassociated with the invocations; (4) transaction-specific requirements(e.g., desired level of accuracy, nature of the transaction, etc.); (5)user-specific requirements (e.g., a user having a cold may prefer not torely on voiceprint match, etc.); and (6) other physical and logicalvariables (e.g., type of network connection—remote or local, quality ofa voice channel, etc.).

The context 108 may also record other variables that representverification scores from external verification sources (not shown). Forexample, a customer entering a bank may have done so after swiping hisbank card at the entrance, and that information could be included in thecontext 108 as an external score and be used for subsequentauthentication processes at the counter or at the automated tellermachine.

The variables initially included in the context 108 are system defaultvariables relevant to the verification objects and other knownrequirements at the time of the initial build. However, as additionalverification objects are added to the system 100 or as new requirementsare discovered, user-defined variables may be added to the context 108.

The network adapter 106 enables communication between the client device102 and the verification server 104. The network adapter 106 implementsnetwork transport protocols, such as the standard Transmission ControlProtocol (TCP)/Internet Protocol (IP) or the Secure Sockets Layer (SSL)protocol. It is to be understood that in an embodiment where theauthentication system 100 is implemented on a single computer system, anetwork adapter is not required.

As shown, the verification server 104 comprises a verification policymanager 112 and a set of verification engines 114-1 through 114-N. Eachverification engine operates on a given verification object or a family(type) of verification objects. For example, a fingerprint verificationengine may operate on a particular fingerprint or different types offingerprints (e.g., thumbprint, index-fingerprint, etc.). Similarly, aknowledge verification engine may operate on different types ofchallenge-response questions.

The flexible architecture allows for easy addition of new verificationengines and verification objects. Verification engines to be added couldbe of a new type or an existing type. For example, a face recognitionengine could be added to a verification server that previously comprisedvoiceprint and fingerprint recognition engines, or a second voiceprintrecognition engine (which could be from a different manufacturer, forexample) could be added. Similarly, new verification objects could beadded to new verification engines or existing verification engines (suchas adding a new question to an existing knowledge verification engine).

The verification policy manager 112 interprets a verification policy fora given user model, and drives the entire authentication process. Thepolicy manager 112 receives the current context 108 from theverification client device 102, operates on the context, incorporatesupdated status of current verification objects, and returns an updatedcontext to the verification client device 102 along with thespecification of the next step to be taken during the verificationprocess.

In one embodiment of the invention, the verification policy manager 112is responsible for invoking states in a finite state machine,interpreting the conditions of the state machine and branching to thenext state. The verification policy manager 112 is the entity that makesthe final accept or reject decision for the authentication process, andin some cases may also make intermediate decisions if the currenttransaction requires such decisions, provided the verification policy ineffect permits it.

The data manager 116 component controls the external storage resources,including verification objects store 118, verification policies store120 and user models store 122. These resources may be accessed directlyby the verification server 104 (either by the verification policymanager 112 or by the individual verification engines 114-1 through114-N). In an alternative embodiment, such resources may be accessed bythe verification client device 102 and shipped to the verificationserver 104 through the network adapter 106.

The application 110 is the application for which user authentication isrequired prior to granting access. Example applications include bankingapplications, travel applications and e-mail applications. Theapplication 110 is responsible for providing application-specific andtransaction-specific information and requirements. It is to beunderstood that the invention is not limited to any particularapplication.

In one embodiment of the invention, the verification client device 102communicates with the verification server 104 using an XML messageinterface. Example functions supported by the interface may comprise thefollowing operations:

-   open a communication channel;-   close a verification or enrollment session;-   begin user enrollment and create a user model;-   end user enrollment and close enrollment session;-   start scoring a verification object;-   end scoring a verification object;-   start a verification session;-   continue a verification session to determine the next state within    policy or output decision;-   add a new verification object;-   add a new verification policy;-   delete verification policies;-   delete context;-   update a verification object to make changes to an existing    verification object;-   update a user model to make changes to an existing user model;-   update a verification policy to make changes to an existing    verification policy;-   query a user model to obtain information within a user model;-   query a verification object to obtain information within a    verification object;-   query a verification policy to obtain information within a    verification policy;-   get a list of active verification objects;-   add a context variable;-   set the current value for a context variable;-   get the current value for a context variable; and-   get a list of all context variable and their current values.

It is to be understood that the above list of operations is not intendedto be exhaustive, and that the invention is not limited to theseparticular example operations.

Further, in alternative embodiments, it is to be understood that thecomponents associated with the verification server may themselvescommunicate with one another over the network adapter 106. Thus, forexample, one or more of the verification engines 114 may communicatewith the verification policy manager 112 over the network adapter 106. Asimilar distributed arrangement may exist with respect to theverification policy manager 112 and the data manager 116, and with thedata manager 116 and the data stores 118, 120 and 122. Thus, it is to beunderstood that the interconnectivity of components shown in FIG. 1 isintended to be illustrative and, therefore, other suitableinterconnections may be implemented to provide the authenticationfunctionality of the present invention.

Referring now to FIG. 2, a block diagram illustrates an exemplarycomputing system environment for implementing customizable verificationusing multiple verification objects, according to one embodiment of theinvention. By way of example, the computing system 200 may represent atleast a portion of a distributed computing system wherein a usercommunicates via a computer system 202 (referred to illustratively as a“client” or client device) with another computer system 204 (referred toillustratively as a “server”) via a network 206. The network may be anysuitable network across which the computer systems can communicate,e.g., the Internet or Word Wide Web, local area network, etc. However,the invention is not limited to any particular type of network. In fact,it is to be understood that the computer systems may be directly linkedwithout a network.

Further, while only two computer systems are shown for the sake ofsimplicity in FIG. 2, it is to be understood that the network may link aplurality of client devices and a plurality of servers. However, it isalso to be appreciated that the techniques of the invention may beimplemented on a single computer system wherein, for example, the userinteracts directly with the computer system that performs theauthentication operations.

With reference to FIG. 1, it is to be understood that the client device102 may be implemented via computer system 202, and that theverification server 104 (and its components), the data manager 116 andthe respective object, policy and user model stores (118, 120 and 122)may be implemented via the computer system 204. Network adapter 106would therefore be implemented in accordance with network 206.

Thus, it is to be understood that FIG. 2 generally illustrates anexemplary architecture for each computer system communicating over thenetwork. As shown, the computer system 202 comprises a processor 208-A,memory 210-A and I/O devices 212-A, all coupled via a computer bus214-A. Similarly, the computer system 204 comprises a processor 208-B,memory 210-B and I/O devices 212-B, all coupled via a computer bus214-B.

It should be understood that the term “processor” as used herein isintended to include one or more processing devices, including a centralprocessing unit (CPU) or other processing circuitry. Also, the term“memory” as used herein is intended to include memory associated with aprocessor or CPU, such as RAM, ROM, a fixed, persistent memory device(e.g., hard drive), or a removable, persistent memory device (e.g.,diskette or CDROM). In addition, the term “I/O devices” as used hereinis intended to include one or more input devices (e.g., keyboard, mouse)for inputting data to the processing unit, as well as one or more outputdevices (e.g., CRT display) for providing results associated with theprocessing unit. Further, the I/O devices associated with the computersystem 202 are understood to include those devices necessary to collectthe particular data associated with the verification objects supportedby the authentication system, e.g., a microphone to capture voice datafor voiceprint recognition and/or answers to questions posed, a speakerto output such questions to the user, a face scanner, an iris scanner, afingerprint scanner, etc.

It is also to be understood that the client computer system illustratedin FIG. 2 may comprise a computer system programmed to implement theinventive techniques such as a personal computer, a personal digitalassistant, a cellular phone, etc. Likewise, the server computer systemillustrated in FIG. 2 may comprise a computer system programmed toimplement the inventive techniques such as a personal computer, amicrocomputer, a minicomputer, etc. However, the invention is notlimited to any particular computer architecture.

Accordingly, software instructions or code for performing themethodologies of the invention, as described herein, may be stored inone or more of the associated memory devices, e.g., ROM, fixed orremovable memory, and, when ready to be utilized, loaded into RAM andexecuted by the CPU.

Referring now to FIG. 3, an example is shown of a registry ofverification objects. In this particular embodiment, the registry 300 isrepresented using XML and stored in the verification objects store 118(FIG. 1).

The specification contains a description of all registered verificationobjects, which can be updated as new verification objects are added. Thefirst object (302) in this example is the Date-of-Birth (DOB) object,which is of the type Question-Answer (QA) and the verification engineresponsible for operating on this object is the knowledge verificationengine. A suggested prompt may also be included to prompt the user forthe required response when this object in invoked, but the prompt may bemodified or replaced by the verification client, if necessary. The“perplexity” is a quantity that represents the difficulty associatedwith the verification object and may optionally be used by theverification policy manager in making verification decisions.

The second object (304) in this example is Caller-ID, which, in the caseof a telephony connection, attempts to match the telephone number of thetelephone originating the call with the telephone number in the relevantuser model. No prompt is specified since this information may beobtained automatically from telephony infrastructure without anyexplicit input from the user.

The third object (306) in this example is the Voiceprint object, and inthis case no type is specified, since the voiceprint verification engineoperates on one type of verification object. Given that voiceprints area biometric feature that may not be stolen, a high perplexity isspecified in this example.

The fourth and fifth objects (308 and 310) illustrate the hierarchicalnature of the specification, whereby the CAR_COLOR object inheritsdefault properties from the parent object COLOR.

The last two objects (312 and 314) in this example are examples ofdynamic verification objects, whereby the intended response changesdynamically, and in this example, the correct responses are obtainedfrom the application, rather than from the user model. The currentbalance (CUR_BALANCE) object (312) is an application-specific object ofthe type numeric (APP_NUM) and the last transaction date(LAST_TRANSACTION_DATE) object (314) is an application-specific objectof the type string.

Referring now to FIG. 4, an example is shown of a user model. In thisparticular embodiment, the user model 400 is represented using XML andstored in the user models store 122 (FIG. 1).

The user model contains a description of verification objects for whichthe user has provided enrollment data. The first object (402) is theCaller-ID object, for which this user's correct response is 914-945-3000in this example. The user's preference for this object may be optionallyincluded and used by the verification policy in selecting objects withhigher preference when possible.

The second and third objects (DOB 404 and COLOR 406) are similar. Thefourth object (color of car or CAR_COLOR 408) has two responses in thisexample, since this user has two cars and either response may beaccepted as the correct answer. The fifth object (410) is the voiceprintobject, for which model parameters are needed, which may be stored in afile, and the filename is included. The last two objects (CUR_BALANCE412 and LAST_TRANSACTION_DATE 414) do not have any correct responsesincluded because they are dynamic verification objects, and the currentcorrect responses have to be obtained from the application.

As mentioned above, in accordance with the present invention, any of theobjects can be updated or deleted in real-time, and new objects can beadded in real-time.

Referring now to FIG. 5, an example is shown of a verification policy.In this particular embodiment, the verification policy 500 isimplemented as a finite state machine and represented using XML. Thecorresponding finite state machine diagram is shown in FIG. 6. Theverification policy 500 is preferably stored in the verificationpolicies store 120 (FIG. 1).

Verification policy 500 depicts a simple policy associated with abanking application. More particularly, the policy governs a situationwhere a user (presumably, a bank client) is trying to gain access tohis/her bank account and the authentication system is verifying theidentity of the user via multiple verification objects, such as thetelephone number of the bank client, the bank client's date of birth,the color of the bank client's car, a voiceprint of the bank client,etc. However, as previously mentioned, the invention is not limited toany particular policy or application. The following illustrativedescription will make reference to line numbers (e.g., lines 1-53)located on the left-hand side of the verification policy 500.

First, in FIG. 5, context variables such as “curBalance” (line 4) and“lastTransactionDate” (line 6) are initialized with default values tohandle dynamic verification objects such as “CUR_BALANCE” and“LAST_TRANSACTION_DATE”. These variables will subsequently be updatedusing inputs from the application. The variable “minVoiceprintScore”(line 5) is used to specify the minimum score acceptable for thevoiceprint match. The default value for this variable is specified bythe verification policy. Different policies may have different defaultvalues (e.g., a stricter policy may have a higher minimum score). In analternative embodiment, the default value may be overwritten by valuesobtained from either the user model (to account for user-specificrequirements) or by the application (to account for transaction-specificor application-specific requirements).

Next, a set of conditions relevant to the policy are specified, whichwill be subsequently used to determine state transitions or evaluateverification objects. The expressions used to define the conditions mayinclude context variables, numerical constants and string literals. Theexpressions may contain operations such as logical AND (&), logical OR(|), equal (=), not equal (!=), less than (<), less than or equal (<=),greater than (>), greater than or equal (>=), multiply (*), divide (/),add (+) and subtract (−).

For example, the condition “ONE_OK” (line 10), which is a condition usedlater to determine state transitions, is satisfied if the total numberof verification objects invoked so far is one (_curObjectNum=1) and itwas a match or there were no mismatches (_curWrongNum=0). Anotherexample of a different kind is the condition “CUR_BALANCE_TEST” (line15). This condition is used to evaluate the current balance(“CUR_BALANCE”) verification object. In this case, a five percent erroris allowed, for example, because an approximate answer is satisfactory.

Following the conditions, a set of states are defined. In this example,there are four states: ACCEPT (line 22), REJECT (line 24), START (line27) and ACCOUNT (line 40). ACCEPT and REJECT are the terminal stateswhere the final verification decision is made. START is the initialstate and contains verification objects “CALLER_ID”, “DOB” and“CAR_COLOR”. By default, verification objects are selected at random,but relative weights may be specified optionally to modify theprobability that an object may be selected. Transition to the ACCOUNTstate occurs if one of the first two conditions (ONE_OK orTWO_OK_ONE_BAD) is satisfied, and transition to the REJECT state occursif the third condition (TWO_BAD) is satisfied.

In the ACCOUNT state, no weights are specified, so all three objectshave equal probability of being selected at random. Further, evaluatingthese objects requires different tests to be used, and these areselected from the previously defined list. Based on the conditionssatisfied, transition to either the ACCEPT state or the REJECT stateoccurs and the corresponding final decision is sent to the verificationclient device 102 (FIG. 1).

In an alternative embodiment, intermediate decisions could be made atthe intermediate states. For example, a decision to accept the user forlow security transactions can be made if certain conditions aresatisfied in the START state, and the final decision to accept the userfor transactions can be made at the ACCEPT state.

Referring now to FIG. 6, a state transition diagram illustrates statetransition for the example verification policy of FIG. 5. Thus, thestate diagram 600 of FIG. 6 illustrates the four states associated withverification policy 500, namely, START (state 602), ACCOUNT (state 604),ACCEPT (state 606) and REJECT (state 608). The arrows between the statesrepresent the conditions for transition between the states, as weredescribed above in the context of verification policy 500 of FIG. 5.

Referring lastly to FIG. 7, a flow diagram illustrates a verificationsession between a verification client device and a verification serverfor the example verification policy of FIG. 5. For instance, such averification session may take place between verification client device102 and the verification server 104 of FIG. 1.

In one embodiment, there are three types of sessions (all of theminvolve opening and closing sessions):

(1) an administrative session where operations such asadding/updating/deleting policies, adding/updating/deleting objects,adding context variables, etc., are performed;

(2) an enrollment session where operations such ascreating/updating/deleting user models, etc., are performed; and

(3) a verification session where operations such as scoring verificationobjects, continuing a verification session and determining a next state,outputting a verification decision, updating/deleting context,setting/getting a value of a context variable, querying usermodels/verification objects/verification policies, etc., are performed.

The administrative session operations may be performed in accordancewith an administrator of the authentication system via a client deviceor directly at the verification server. The enrollment and verificationsessions may be performed in accordance with a user via a client deviceor directly at the verification server.

The flow chart of FIG. 7 depicts an example operation flow 700 for averification session, given the verification policy 500 of FIG. 5.

As shown, in step 702, the client initiates the verification sessionwith the server, stating the name of the policy (SIMPLE_BANK_POLICY) andthe username (John Doe), with a default context. The server retrievesthe policy and the user model referenced.

The server operates on the policy and the user model, and determines thefirst verification object to be invoked (DOB, in this example). Theserver updates the context and sends the request for that object and thecontext to the client, in step 704.

The client acquires the response to the invoked verification object(“DOB=08-02-1975”), and sends the response to a server, in step 706,along with the current context. As mentioned above, in an embodimentutilizing more than one server, the response need not be sent to theinitial server, but rather it may be sent to another server in theauthentication system. This is due to the stateless client-server natureof communication that may exist in such an embodiment.

The server (initial or other server) then scores the verificationobject, updates the context, determines the next state in the policy,and selects and sends the next verification object from the list ofavailable objects (CUR_BALANCE, in this example) along with the updatedcontext to the client, in step 708.

Since the CUR_BALANCE object is a dynamic object with frequentlychanging answers, the client updates the relevant context variable withthe current value obtained from the application (curBalance=10000), instep 710. In step 712, the server returns acknowledgment to step 710.

The client acquires the response to the invoked verification object(CUR_BALANCE=10000), and sends the response to a server, in step 714,along with the current context.

The server then scores the verification object, determines that thepolicy has been satisfied, and outputs an “ACCEPT” decision, in step716. The client then ends the verification session.

It is to be understood that an enrollment session and an administrativesession would have respective request-response pairs between the clientand the server that are particular to the operations performed in thosesessions. It is to be further understood that in an embodiment where theauthentication system is implemented on a single computer system, theuser interacts directly with the single computer system in performingthe operations associated with the particular session.

Although illustrative embodiments of the present invention have beendescribed herein with reference to the accompanying drawings, it is tobe understood that the invention is not limited to those preciseembodiments, and that various other changes and modifications may bemade by one skilled in the art without departing from the scope orspirit of the invention.

1. An automated method of user authentication implemented by at leastone processor, the method comprising the steps of: obtaining user input,wherein at least a portion of the user input is associated with two ormore verification objects; and verifying the user based on the two ormore verification objects in accordance with at least one verificationpolicy operating on a context shared across the two or more verificationobjects.
 2. The method of claim 1, wherein the user verification step isperformed in accordance with two or more verification engines which arerespectively responsive to the two or more verification objects.
 3. Themethod of claim 2, wherein the two or more verification enginesrespectively compare the two or more verification objects to at leastone user model.
 4. The method of claim 3, wherein the at least one usermodel is shared across the two or more verification objects.
 5. Themethod of claim 3, wherein the at least one user model is previouslygenerated based on data obtained in accordance with a user enrollmentsession.
 6. The method of claim 1, wherein the context comprises one ormore variables associated with the user verification step.
 7. The methodof claim 6, wherein the one or more context variables represent one ormore of: (i) a user name; (ii) a current state in the at least oneverification policy; (iii) a history pertaining to the two or moreverification objects; (iv) application-specific requirements; (v)user-specific requirements; and (vi) physical or logical variables. 8.The method of claim 1, wherein the two or more verification objectsrepresent at least one of an object type that may be used to verifyidentity of the user, knowledge of the user, and possessions of theuser.
 9. The method of claim 1, further comprising the step of acceptingat least one of the addition of, the modification of, and the deletionof at least one of a verification policy, a verification object type, auser model, and a variable associated with the context, for subsequentuse in the user verification operation.
 10. The method of claim 1,wherein the context comprises a finite state machine defining statetransitions for the user input associated with two or more verificationobjects and the results associated with the user verification operationin accordance with the at least one verification policy.
 11. An articleof manufacture for use in user authentication, comprising a machinereadable medium containing one or more programs which when executedimplement the steps of claim
 1. 12. The article of claim 11, wherein theuser verification step is performed in accordance with two or moreverification engines which are respectively responsive to the two ormore verification objects.
 13. The article of claim 12, wherein the twoor more verification engines respectively compare the two or moreverification objects to at least one user model.
 14. The article ofclaim 11, wherein the at least one user model is shared across the twoor more verification objects.
 15. The article of claim 14, wherein theat least one user model is previously generated based on data obtainedin accordance with a user enrollment session.
 16. The article of claim11, wherein the context comprises one or more variables associated withthe user verification step.
 17. The article of claim 16, wherein the oneor more context variables represent one or more of: (i) a user name;(ii) a current state in the at least one verification policy; (iii) ahistory pertaining to the two or more verification objects; (iv)application-specific requirements; (v) user-specific requirements; and(vi) physical or logical variables.
 18. The article of claim 11, whereinthe two or more verification objects represent at least one of an objecttype that may be used to verify identity of the user, knowledge of theuser, and possessions of the user.
 19. The article of claim 11, furthercomprising the step of accepting at least one of the addition of, themodification of, and the deletion of at least one of a verificationpolicy, a verification object type, a user model, and a variableassociated with the context, for subsequent use in the user verificationoperation.
 20. An automated method of authenticating a user implementedby an authentication system, the method comprising the steps of:verifying the user in accordance with the verification means; andcustomizing the user verification means for subsequent userverification.
 21. An automated method of authenticating a userimplemented by an authentication system, the method comprising the stepsof: obtaining user input; and verifying the user based on at least aportion of the user input in accordance with at least one verificationpolicy, wherein the at least one verification policy is implementable asa state machine.
 22. The method of claim 21, wherein the verifying stepfurther comprises outputting at least one of an intermediate decisionand a terminal decision.
 23. An automated method of authenticating auser implemented by an authentication system, the method comprising thesteps of: obtaining user input, wherein at least a portion of the userinput is associated with at least one verification object; and verifyingthe user in accordance with the at least one verification object,wherein the at least one verification object is at least one of: (i)usable for verification without the use of an associated verificationengine; (ii) not required to be previously enrolled with user datarelating to the at least one verification object; (iii) dynamic; (iv)implicit; (v) able to inherit at least one property from another object;(vi) characterized by multiple inputs; (vii) weighted; and (viii) ableto be manipulated.
 24. An automated method of authenticating a userimplemented by an authentication system, the method comprising the stepsof: obtaining at least one user model; and verifying a user inaccordance with the at least one user model, wherein the at least oneuser model is at least one of: (i) representative of one or more userpreferences; and (ii) able to be modified for use in subsequent userverification.
 25. An automated method of authenticating a userimplemented by an authentication system, the method comprising the stepsof: obtaining at least one verification policy; and verifying a user inaccordance with the at least one verification policy, wherein the atleast one verification policy is based on a verification object, one ormore context variables and external source data.